\section{Context/Problem Statement} \label{sec:context}

In this section, we first present the flow model for access control data, which depicts the relationships between the PDP and the PEPs.
We next present the performance issues in XACML access control policies and the synergy property that we aim to preserve in our automated process 
of refactoring.

\subsection{Flow Model for Access Control Data}

Most access control scenarios involve an access control policy which is modeled, analyzed and implemented as a separate component
 encapsulated in a PDP, which interacts with the business logic through the PEP that deals wirh access control requests. 
Figure \ref{pep-pdp} illustrates that the PEP in turn calls the PDP to retrieve an authorization decision based on the PDP encapsulated
policy. This authorization decision is made through the evaluation of rules in the policy. 
Subsequently, an authorization decision is returned to the PEP.
The separation between the PEP and the PDP in access control systems simplifies policy management across many heterogeneous systems and enables to avoid
 potential risks arising from incorrect policy implementation, when the policy is hardcoded inside the business logic.
\\
In this paper, we focus on access control decision making for policies expressed in XACML.
XACML \cite{sunxacml} is a standard policy specification language that defines a syntax of access control policies in XML.

\begin{figure}[!h]
\begin{center}
\includegraphics[width=9cm, height=8cm]{business-logic}
\caption{Access Control Request Processing}
\label{pep-pdp}
\end{center}
\end{figure}

\subsection{XACML Access Control Policies and Performance Issues}
%\begin{figure}[!h]
%\begin{center}
%\includegraphics[width=12cm, height=10cm]{optimisation.jpeg}
%\caption{\label{XACML Architecture}XACML Architecture}
%\end{center}
%\end{figure}
In the XACML paradigm, a policy set element involves a sequence of policies, a combining algorithm and
 a target. A policy element is expressed through a target, a set of rules and a rule combining algorithm. 
The target defines the set of resources, subjects and actions to which a rule is applicable. The rule element  of a 
target, a condition, and an effect. The condition is a boolean expression that specifies restrictions (e.g., time and location restrictions) on the elements in the target. It represents 
the environmental context in which the rule applies. Finally, the effect element is either permit or deny. 
When more than one rule is applicable to a given request, the combining algorithm enables selecting which rule to choose.
For example, given two rules, which are applicable to the same request and provide different decisions,
the permit-overrides algorithm prioritizes a permit decision over the other decision.
More precisely, when using the permit-overrides algorithm, the policy evaluation engenders the following three decisions: 
\begin{itemize}
\item Permit if at least one permit rule is applicable for a request.
\item Deny if no permit rule is applicable and at least one deny rule is applicable for a request.
\item NotApplicable if no rule is applicable for a request.
\end{itemize}

Figure \ref{figur1} shows a simple XACML policy that denies subject Bob to borrow a book.
\fontsize{5}{5}
\begin{figure}[!h]
\begin{center}
\includegraphics[width=8.6cm]{xacml}
\caption{XACML Policy Example}
\label{figur1}
\end{center}
\end{figure}

The XACML request encapsulates attributes that define which subject is requested to take an action on which protected resource in a system.
It can also include a condition. A request, which satisfies both target and condition in a rule, is evaluated
to decision specified in the rule's effect element. If the request does not satisfy target and condition elements in any rule, its response yields ``NotApplicable'' decision.
\\XACML enables administrators to externalize access control policies for the sake of interoperability since access control policies can be designed 
independently from the underlying programming language or platform. Such flexibility enables to easily update the access control policy to support new requirements.
%\centering
%\figure[DREF metamodel\label{fig:drefMM}]
%        {\includegraphics[width=0.5\textwidth]{figure/drefMM}}
%\figure[SETER Process: Security Testing for Resilient Systems 
%\label{fig:seter}] {\includegraphics[width=0.49\textwidth]{figure/seter}}
%\caption{DREF and SETER: Conceptual and Operational Frameworks for evaluating resilient systems}
%\end{figure*}

However, the increasing complexity of organizations in term of structure, relationships, activities, and access control requirements has impacted 
access control policy design. This has led to deal with access control policies where the number of rules depicting the associations between resources, 
users and actions is huge. Moreover, the policy is usually centralized in a single point PDP, which 
has to manage multiple access control requests.

These observations raise performance concerns related to request evaluation time for XACML access control policies. 
In fact, performance bottlenecks degrade the system efficiency which slows down the overall business processes. 
Considering XACML request evaluation, many factors may lead to reducing XACML requests evaluation performance.  
\\
Next, we present some of the factors that are causing this performance issue in XACML architecture:

\begin{itemize}
\item An XACML policy may contain several attributes that constitute descriptive information about the target elements, the retrieval of
 varying size of attributes values for each request within XML elements in a request, may increase the evaluation time.
\item A PolicySet includes a set of policies, the effect of the whole
PolicySet is determined by combining the effects of the policies according to a combining algorithm, the computation of resulting effect 
from policies is also considered as a potential evaluation time latency.
\item Conditions evaluation in XACML rules may slow down the decision making process since these conditions can be complex because they can 
be built from an arbitrary nesting of non-boolean functions and attributes. 
\end{itemize}


\subsection{Preserving The Access Control Architecture}
Managing access control policies is one of the most challenging issues faced by organizations. 
Frequent changes in access control systems may be required to meet business needs. An access control system has to handle some specific 
requirements like role swap when employees are given temporary assignments, changes in the policies and procedures, 
new assets, users and job positions in the organization.
All these facts make access control architectures very difficult to manage, and plead in favor of a 
simple access control architecture that can easily handle changes in access control systems. 
Along with the reasoning about performance, we propose to maintain the simplicity of the access control architecture whose model 
is presented in Figure \ref{model}.

In this model, a set of business processes, which comply to users' needs, are encapsulated in a given business logic which is enforced 
by multiple PEPs. Conceptually, the decision is decoupled from the enforcement and involves a decision making process in which each PEP interacts 
with one PDP, thus a single XACML policy is evaluated to provide the suitable response for an access control request provided by a PEP. 

Considering a single XACML policy file for each initiating PEP enables to:
\begin{itemize}
 \item Ease policies management.
\item  Maintain a simple architecture where suitable decision points are triggered by a PEP for given requests.
\end{itemize}

For this sake, we propose to preserve the cardinality based property between the PEP and the PDP.
In such configuration, a PEP triggers always the same PDP encapsulating the policy related to that PEP requests. 
One of the advantages of such architecture is that when there is a bug in a given PEP in the system, it is 
easy to localize the corresponding policy and to check the problem. 
Therefore, We aim at proposing a strategy that increases request evaluation performance and that preserves this property, 
which holds for the initial architecture. The next section describes our approach and gives an insight of the process supporting it.


\begin{figure}[!h]
\begin{center}
\includegraphics[height=4.5cm,width=8cm]{model}
\caption{The Access Control Model}
\label{model}
\end{center}
\end{figure}
